fixes evaluation order of stack trace #8568
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This version works for ant projects.
homberghp
changed the title
homberghp
changed the title
|
solves #8567 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This version works for ant projects. (Including netbeans projects).
This PR closes #8567
This implementation of finding file object+line number reverses the search by starting at the top of the stack and try to find the stack frame that is directly related to the test method.
It reverses the loop running from bottom to top into running from the top stack frame to the bottom one.
It effectively tries to find the first stack element that matches the testMethod involved instead of the first element that is NOT in some (testing) framework. For most tests this appears to be the logical choice, in particular in the non-optimal practice of having multiple assert or assert-like statements in one test method.
For NetBeans developers, in particular those working on refactoring related stuff and tests, it is more useful to point to the failing assert or verifyXXX call than in some method inside some method inside the test class or a superclass thereof that generalizes repetitive work in the tests.
In the original the goto source landed me in
netbeans/java/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/RefactoringTestBase.java
Lines 405 to 418 in 68e420d
instead of say line 118 below, which is the more logical line to choose in most cases.
netbeans/java/refactoring.java/test/unit/src/org/netbeans/modules/refactoring/java/test/InnerToOutterTest.java
Lines 117 to 118 in 68e420d
This PR solves the problem for both maven and ant projects in a similar way.